A distributed database is a relational database whose information may be replicated out to multiple user databases. Although dispersed, a distributed database system manages and controls the entire database as a single collection of data. Distributed databases often get updates from multiple users while in operation. In normal operation, a distributed database is accessed by a user and a portion of the information is changed. The changes can be saved back to the database and then distributed out to some or all of multiple other users for their reference. This is done because changes made by one user can affect another user if the data that one user is manipulating is the same data that another user is relying on. Often, the multiple users access the same data at different times and can manipulate that data in different ways before returning it to the database to be saved. Conflicts can arise in a distributed database system as a result of moving a data set or image to and from a users database. For example, a conflict can arise due to multiple updates on the same data set image from multiple users. The distributed database management system must resolve the multiple user changes in order to keep a properly updated and consistent database core. Conflicts arising from multiple users changing the same data can be resolved in the central database of the replication system. Conflict resolution rules can be established based on many factors including but not limited to the type of database, its application, and the hierarchical status of the one user over another.
Data changes and the statistics of the changes, such as who made the changes and when, are stored in metadata with the data of record in the database. In large databases with a large number of users, the conflict metadata can become so large that system stability, scalability, and performance are adversely affected. Large amounts of saved metadata also require large amounts of storage which can be difficult to accommodate if metadata continues to grow. One prior art method of dealing with the growth and convergence difficulties of accumulating a vast quantity of metadata is to set time deadlines for change updates. For example, in a large system with hundreds of users, metadata may be stored for a week so that, among other tasks, conflict resolution may occur. In this instance, it may be necessary to save metadata change history for a week so that a full conflict resolution concerning all changes can be accommodated.
In the current example, at the end of the one week period, the metadata has grown to a point where the storage capacity or the performance of the database may be at a constraint to system performance. Change metadata needed for conflict resolution is then removed. By removing the change metadata, the database system may avoid problems associated with excess metadata such as lack of convergence, stability, storage or performance. However, changes not submitted before the change metadata removal are unable to be accommodated. The user submitting the changes must download a new set of data from the database and start from that point without his earlier changes being entered.
This metadata management technique, although commonly used, can force many users who did not get their changes in before the cutoff time to loose their changes and start over by downloading new information. Also, this may be inequitable to the user who is manipulating a piece of data that no other user is accessing. In a scheme where multiple users can access overlapping portions of data, changes submitted to and resolved by the database are transmitted to other users who have requested the same data so that all users may utilize the most current version of the data they are viewing. Users who have not actively requested the same portion of data do not get updates on data that they are not using. This scenario, coupled with the cutoff deadline for changes discussed above, sets up the inequitable requirement that a sole user of a specific portion of data who does not submit his changes before the cutoff deadline loses his ability to incorporate those changes even though no other user is viewing or manipulating his specific portion of the database. However, this is a heretofore necessary, but adverse, consequence of the use of a cutoff deadline rule for the management of change metadata.
Thus, there is a need for a distributed database management method and system which manages change metadata such that data changes not submitted by a change deadline are not universally lost by all users incorporating a change deadline management scheme. The present invention addresses the aforementioned needs and solves them with additional advantages as expressed herein.